Registries report which commands they support. #5915
Conversation
In the `config.json` of each registry's index, that registry can report
which commands it supports, under which versions. For example, crates.io's
config.json should look like:
```json
{
"api": "https://crates.io/",
"dl": "https://crates.io/api/v1/crates",
"commands": {
"publish": ["v1"],
"yank": ["v1"],
"owner": ["v1"],
"search": ["v1"],
"login": ["v1"]
}
}
```
Currently, these five commands only have one version, "v1," but this allows us
to release new, breaking changes to these commands' interface with crates.io
without disrupting the operation of any alternative registry.
Before this is merged, crates.io's config.json will need to be updated, and we
should make an effort to inform known maintainers of alternative registries
that they need to update their indices as well.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
☔ The latest upstream changes (presumably #5939) made this pull request unmergeable. Please resolve the merge conflicts. |
|
Looks reasonable to me! @sfackler as the other "co champion" of custom registries, do you have thoughts on this? |
| Some(registry) => registry, | ||
| None => "crates-io", | ||
| }; | ||
| Err(format_err!("`{}` does not support the `cargo login` command with \ |
There was a problem hiding this comment.
We should only check this if the token wasn't provided up front right?
|
LGTM other than making sure that |
|
@sfackler why should that work? If the registry doesn't support the v1 login flow, that wouldn't be meaningful. If they do support it, they should report that they do. Imagine that we implement a new login flow in which |
|
What's the scope of the v1 login flow? Part of the v1 publish flow is that an |
|
That's a good question, and I see why you would think your registry doesn't support the v1 flow. I do just think it means storing an API token and passing it with the
This should also be changed so that registries that don't assert they support a login flow but do support other commands are sent requests without any auth header (such registries are presumably relying on being run on an intranet, not saying its a good idea but its the semantic result of saying you support publish but not login) |
|
This feature is blocking custom registries landing, which is unfortunate. The main blocker on the PR has been that I have a lot of difficulty understanding how to cargo's test suite actually sets up the environment, so I've never been able to get CI to pass. |
|
@withoutboats sorry for the late reply, but could I help out perhaps with getting |
|
Closing per discussion in #6442. |
In the
config.jsonof each registry's index, that registry can reportwhich commands it supports, under which versions. For example, crates.io's
config.json should look like:
{ "api": "https://crates.io/", "dl": "https://crates.io/api/v1/crates", "commands": { "publish": ["v1"], "yank": ["v1"], "owner": ["v1"], "search": ["v1"], "login": ["v1"] } }Currently, these five commands only have one version, "v1," but this allows us
to release new, breaking changes to these commands' interface with crates.io
without disrupting the operation of any alternative registry.
Before this is merged, crates.io's config.json will need to be updated, and we
should make an effort to inform known maintainers of alternative registries
that they need to update their indices as well.
This also involved rewriting the initial stage of the
cargo loginflow to be abit more clear.